昨天提及系統的 In Scope 與 Out of Scope，但知道要做什麼跟能動手寫 code，中間還差了一大截。以我們的代購 App 為例：如果只是把買家講的「我想知道東西換算成台幣多少錢」直接丟給工程師，十個人可能寫出十種東西——有人做成頁面上多一行字，有人做成需要手動按按鈕才換算，有人乾脆漏掉匯率過期要怎麼處理。落差不是誰的錯，是兩邊看系統的角度本來就不同。這篇要介紹三套工具，讓需求從一句話變成雙方都懂、也做得出來的規格。

一、使用者故事（User Story）

定義：以終端使用者的角度出發，用簡潔的日常語言描述系統功能的需求，重點在商業價值，而不是資料庫欄位或介面按鈕長什麼樣。

標準公式：作為 As（角色）、我想要 I want to（動作）、以便達到 So that（價值）。

用代購 App 的例子寫一次：

作為代購 App 的買家，我想要在瀏覽商品時就看到換算成新台幣的價格，以便我在下單前就能判斷這筆代購划不划算。

3C 原則：卡片 Card 是提醒需求的簡短記錄；對話 Conversation 是利害關係人跟開發團隊針對細節持續討論；確認 Confirmation 則是確認需求已經達成、可驗證的驗收標準。

INVEST 原則：好的 User Story 應該是獨立（Independent）、可協商（Negotiable）、有價值（Valuable）、可估算（Estimable）、夠小（Small）、可測試（Testable）。

二、使用案例（Use Case）

定義：一種結構化描述，詳細記錄參與者與系統之間為了完成特定目標的互動過程。

同一個換算功能，寫成 Use Case 會長這樣：

• 案例名稱：查詢商品新台幣換算金額
• 主要參與者：買家
• 前置條件：買家已登入，該商品已標示原幣別與價格
• 主要成功流程：買家開啟商品頁 → 系統抓取即時匯率 → 系統計算並顯示換算後金額
• 例外流程：若匯率 API 無回應，顯示最近一次快取匯率，並標示更新時間
• 後置條件：買家看到換算金額，可繼續決定是否下單

三、驗收標準（Acceptance Criteria）

定義：一組預先定義、具體且可衡量的條件，用來界定功能在什麼情況下算是完成，也是測試人員撰寫測試案例的依據。

常見格式是 Given-When-Then：

Given 買家瀏覽一件標價 100 美金的商品
When 頁面載入完成
Then 頁面應顯示換算後的新台幣金額，且與當下即時匯率的誤差在 0.5% 以內

核心特徵：語意清楚（Clarity）、可測試（Testability）、結果導向（Outcome-focused）、彼此獨立（Independence）。

四、結論

把同一個功能——匯率換算——分別寫成 User Story、Use Case、Acceptance Criteria 之後，我才真正理解這三者不是三套各自獨立的文件，而是同一件事的三個切面：User Story 講為什麼要做，Use Case 講怎麼互動，Acceptance Criteria 講怎麼判斷做完了。一開始對這些名詞我幾乎一無所知，更別談背後的定義是什麼——User Story、Use Case、Acceptance Criteria、3C、INVEST，光是把這些字丟出來就先卡住了。真正讓我搞懂三者差異的方法，不是把定義多讀幾遍，而是透過實作——把同一個「查詢商品換算金額」功能，逼自己用三種格式各寫一次，才慢慢有感覺哪句話該放進 User Story，哪句該放進 Use Case，哪句又只是 Acceptance Criteria 在做的事。